Software development is a big investment, requiring a minimum of six figures and often far more. So why do so many companies throw away their investment? Why do they trash existing software and rewrite it from scratch? Why do they retire useful products?

Companies often make these painful decisions because their software has become too expensive to maintain. Over time, changes become more costly. Eventually, the cost is too high: the company has to retire the product or rewrite it.

When the cost of change increases, it's because the design quality is decreasing. Since retiring or rewriting software means writing off a huge investment, you wouldn't expect any team to let design quality deteriorate to that point. Yet it happens all the time. Why?

"Design debt" explains the problem. When a team is working under pressure, they take shortcuts that compromise design quality. It's like taking out a high-interest loan. The team gets a short-term boost in speed, but from that point forward, changes are more expensive: they're paying interest on the loan. The only way to stop paying interest is to pay back the loan's principle and fix the design shortcuts.

Most teams don't think in terms of design debt and don't even try to pay back principle. If you have a project with an aggressive deadline, your team has almost certainly taken on design debt. It's already slowing them down, and in order to avoid missing deadlines, they'll take on more debt. The compound interest will eventually kill your investment.

You can break the cycle, but it takes discipline and willpower. Start by letting your team know that design debt is unacceptable. Introduce them to continuous design, refactoring, and other code-quality practices. Then follow through by providing time for them to use the practices.

Avoid the temptation to stop work and refactor for several weeks. Even the most disciplined team inadvertently takes on design debt, so eliminating debt needs to be an ongoing activity. Have your team get used to refactoring as part of their daily work.

Design debt is like credit card debt: it's easy, tempting, and leads to ruin if not paid off. Nearly every team can go faster by reducing design debt. Demand continuous design improvement from your teams. Support it by reducing schedule pressure and training your teams in advanced code-quality practices. The extra effort now will safeguard your investment for the future.

Design debt can be hard to spot. If you see these problems, your project is already in serious trouble:

• Your team describes the software as "kludgey" or "hacked-together."
• The team often encounters unexpected problems.
• Each change results in a cascade of new defects.
• Defects thought fixed frequently reappear.

To avoid the above level of debt, make debt elimination a priority:

• Reduce schedule pressure.
• Establish a culture of design quality.
• Utilize refactoring, continuous design, and other code-quality practices.
• Make debt reduction a continuous process, not a one-time activity.

(Note: The debt metaphor was coined by Ward Cunningham. It's also known as "technical debt" or "software debt.")